onyxOS Payer API Documentation

Background

The Payer-to-Payer (Bulk) API allows a new health plan to securely request and receive member data from a prior health plan, after the member gives consent. It supports the bulk exchange of clinical and administrative data using standard FHIR APIs and helps payers meet CMS interoperability and prior authorization requirements.

The Relevant implementation Guides are:

• Payer-to-Payer Exchange (bulk) - Da Vinci Payer Data Exchange v2.1.1

The Payer Data Exchange (PDex) IG incorporates the data profiles defined in the US Core 3.1.1 IG.

Accessing the APIs

• Secure access : Payers use server-to-server authentication (OAuth 2.0 client credentials) to securely access the bulk Payer-to-Payer APIs.
• Member consent required : Data can only be requested and shared after the member has given consent, and consent is checked for each request.
• Limited data scope : Shared data is limited to the last 5 years of clinical data, with prior authorization data limited to current or recently updated records (within 12 months), including any required supporting documents.

To register an app Payer can go to the Payer Portal.

onyxOS, the Interoperability Rule and FHIR Implementation Guides

onyxOS has been designed to convert FHIR Implementation Guides into APIs. onyxOS can ingest a capability statement and create the required APIs together with the relevant member-level access controls.

In order to comply with the CMS Interoperability Rule we provide access to the following resources to support developers who are creating applications that make use of the IGs identified in the previous section.

• Implementation Guides
• Capability Statements
• Swagger Files
• Postman Collections

Implementation Guides

For developers who are not familiar with HL7 FHIR Implementation Guides (IGs). An IG provides detailed information on data structures for resource profiles. It also provides information on Search parameters and other technical aspects of the use cases that the IG was designed to address. Each IG builds on the base FHIR Release 4 specification for elements such as, field definitions and data types.

You are strongly encouraged to refer to the introductory sections of each IG. The introduction will provide a context to the use cases the guide addresses. This can have implications for how the information is accessed and the type of searches that are supported.

The links to each guide are provided below:

• Payer-to-Payer Exchange (bulk) - Da Vinci Payer Data Exchange v2.1.1

Capability Statements

Server Capability Statements define the data profiles, operations, access methods and search operations that are supported by the server.

The Capability Statement can be referenced using the [base_url][/ig_name]/metadata endpoint.

When working with different client instances of onyxOS, the content of the capability statements will be the same with just the [base_url] value changing to point to a different environment.

Swagger Files

onyxOS creates OpenAPI.json files, frequently referred to as swagger files from the Capability Statements provided. The swagger files enable developers to better understand the server interactions.

Swagger files are available for download using the same endpoint conventions as for capability statements. Therefore, if a Capability Statement is at:

• [base_url][/ig_name]/metadata

The openapi.json file will be found at:

• [base_url][/ig_name]/openapi.json

onyxOS also provides a swagger UI for each openapi.json file. the links for the appropriate IGs are as follows:

Postman Collections

Postman is a popular API tool used by Developers. The Onyx Development team have provided a set of Postman collections to accelerate development of apps that use the FHIR APIs published by the SAFHIR platform.

[]: